02/22A2005 15:56 4073437587 FAX PAGE 10 



Amendments to the Drawings 
Block 810 of Fig. 8 is amended to correct a typographical error (changing "deparmentV 
to "department's"). No new matter is introduced with this amendment. 
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REMARKS 

Claims 1, 5 - 7, 10 - 1 1, and 14 have been amended. Claims 3 - 4, 9, and 13 have been 
cancelled from the application without prejudice. Claims 15 - 18 have been added. No new 
matter is added with these amendments, which are supported in the specification as originally 
filed. Claims J , 5 - 7, 10 - 1 1, and 14 - 18 are now in the application. 

I. Proposed Correction to the Drawing s 

A proposed replacement drawing is submitted herewith for Fig. 8. Hie correction made 
in this replacement drawing is discussed above in "Amendments to the Drawings". No new 
matter is introduced with the replacement drawing. 

n. Rejection Under 3 5 U.S.C. 8102(b) 

Paragraph 9 of the Office Acti on dated December 22, 2004 (hereinafter, "the Office 
Action") states that Claims 1, 3, 4, 6, 7, 9, 1 1 , and 13 are rejected under 35 U.S.C. §102(b) as 
being anticipated by Rubin (U. S. Patent 5,412,797). Claims 3 - 4, 9, and 13 have been cancelled 
from the application without prejudice. This rejection is respectfully traversed with regard to 
remaining Claims 1,6-7, and 11. 

Applicants' independent Claims 1, 7, and 1 1 have been amended herein to more clearly 
specify limitations pertaining to associations and the ends thereof. In particular, Claim 1 (for 
example) specifies that an association end "reflects an association from an instance of a first class 
to an instance of a second class" (line 4) and that the association has "an inverse association end 
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.» to reflect an inverse association from the instance of the second class to the instance of the first 
class" (lines 10 - 1 1 and 19 - 20). Applicants 7 specification uses the term "bi-directional links" 
to characterize this scenario where a association has an inverse, and can be navigated in both 
directions (that is, from the instance of the first class to the instance of the second class, as 
described in line 4 of Claim I and vice versa, as described in lines 10 - 1 1 and 19 - 20 of Claim 
l);seep. 15 ? lines 1 ~4. 

Rubin teaches techniques whereby "relations" are maintained using pointers in source 
instances and in sink instances. See, for example, col. 2, lines 46 - 5 1 . In particular, a source 
instance points to the (1 ) first and (2) last sink instances in a ring of sink instances (col 2 line 
48), and a sink instance points to (1) the next sink instance in this ring, (2) the previous sink 
instance in this ring, and (3) the associated source instance (col. 2, lines 49 - 5 1 and lines 52 - 
57). 

In a scenario where there are 3 or more sink instances, Rubin's source instances da not 
poiattp 3U of the sink instances - rather, his source instances point only to 2 of those sink 
instances (that is, to the "first" sink instance and the "last" sink instance in a ring, as noted 
above). Furthermore, Rubin specifically notes, at col. 18, line 43 - col- 19, line 2, that his 
invention can be employed such that his relationships can be inserted or removed without 
requiring access to source instances. This is because each sink instance stores onl^a pointer to 
its source instance. Thus, using the procedure discussed in this cited text, a new sink instance 
must always be inserted such that it is neither the first sink nor the last sink . This restriction is 
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necessary because the source instance does need to be updated if its first sink or last sink pointers 
are changed. The cited text therefore states that the source instance can be initialized to use 
"dummy" sink instances as the first and last sink instances of a ring, and thereafter all "real" sink 
instances are inserted in between those dummy instances (see, in particular, col. 18, lines 65 - 
67). Using this approach, only the next sink pointers and previous sink pointers of g£uk instances 
in the ring need to change: the newly-inserted sink instance merely includes a reference (i.e., 
pointer) to the previously-created source instance. Thus, there is no modification of the "source 
end" of Rubin's relationship (see col 19, lines 1 - 2, stating that neither read nor write access to 
the source instance is required; see also col. 19, lines 48-51, stating that Rubin's relationships 
can "sometimes" be removed without having read or write access to the source instance ~ 
provided, apparently* that the approach of using dummy instances has been followed). 

This is in contrast to Applicants 5 claimed invention, whereby each end of an association 
is changed when either of the ends is to be set - thai is, the end to be set and its inverse are both 
changed. See the second and third limitations of Applicants 1 independent claims, where in the 
second limitation, "setting" steps are specified for both of the association ends and in the third 
limitation, an "adding" and a "setting" step are specified. 

Applicants further respectfully note that the analysis presented on page 4 ? line 12 - page 5, 
line 2 of the Office Action has misinterpreted "single multiplicity**, as that term is used in 
Applicants' invention. In particular, Rubin's "presents* relationship has a many multiplicity, not 
a single multiplicity. That is because the source of a "presents" relationship, according to 
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Rubin's example, may have many related sink instances. This is similar to Applicants' 
"employees* association end, where the source of the "employees" association namely, a 
particular Department instance - may have many associations to particular Employee instances. 
In Rubin's example, the <c isPresentedBy" relationship is the one that has the single multiplicity - 
because, as in Applicants 5 example whereby a particular Employee instance has a "department" 
association with at most one Department instance, each of Rubin's sink instances 
"isPresentedBy" at most one source instance. Thus, in contrast to the statement on p. 4, lines 14 
- 16 of the Office Action, Rubin's "presents" relationship has the u many" multiplicity precisely 
because it can be associated to, or presents, more than one sink instance. 

In addition, the statement on p. 4, lines 9 - 10 of the Office Action misinterprets this 
single-multiplicity and many-multiplicity concept. As stated therein, Rubin* s one-to-many 
relationships have both single and many multiplicity. As the "single multiplicity" and "many 
multiplicity" terms are used in Applicants* invention, by contrast, they consider only the upper 
bound of the multiplicity. For example, a one-to-manv (or zero-to-many) association end has 
only the tnaay multiplicity. Its inverse, if and only i f it is a one-to-one association end, has the 
single multiplicity. This is illustrated in Applicants' Fig. 2, where association end 210, for the 
"department" association end, is denoted as "1..1" - that is, a one-to-one association end - 
whereas association end 220, for the "employees" association end, is denoted as "0..*" - that is, 
a zero-to-many association end. Page 4, lines 3 - 4 and lines 7 - 8 of Applicants' specification 
refer to these "1 ..1" and "0..** notations as indicating the multiplicity of the association ends; 
examples provided in Applicants' specification then use the terms "single" and "many" 
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multiplicity, respectively. (Note that each end of Applicants' associations are directional: that is, 
the claimed ''request to set an association end" reflects an association from the instance of the 
first class to the instance of the second class, and the claimed "inverse association end" reflects 
an association from, the instance of the second class to the instance of the first class.) 

In view of the above, Applicants respectfully submit that their independent Claims 1, 7, 
and 1 1 are patentable over Rubin. Dependent Claim 6 is therefore deemed patentable over Rubin 
as well. Accordingly, Applicants respectfully request that the Examiner withdraw the §102 
rejection. 

HI. Rejection Under 35 II S C. § 1 03f a ) 

Paragraph 1 1 of the Office Action states that Claims 5, 10, and 14 are rejected under 
35 U.S.C. § 103(a) as being unpatentable over Rubin in view of Johnson (a publication from 
javaworld.com). This rejection is respectfully traversed. 

As demonstrated above, Rubin feils to render Applicants' independent Claims 1, 7, and 
1 1 unpatentable. Rubin and Johnson therefore cannot be combined (assuming, arguendo, that 
one of skill in the art would be motivated to attempt such combination and that such combination 
can, in fact, be made) to render Applicants* dependent Claims 5, 1 0, and 14 obvious. 
Accordingly, Applicants respectfully request that the Examiner withdraw the §1 03 rejection. 
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IV. Conclusion 

Applicants respectfully request reconsideration of the pending rejected claims, 
withdrawal of all presently outstanding rejections, and allowance of all remaining claims at an 
early date. 



Respectfully submitted, 



Marcia L. Doubet 
Attorney for Applicants 
Reg. No. 40,999 



Customer Number for Correspondence: 43 1 68 
Phone: 407-343-7586 
Fax: 407-343-7587 
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